Читать статью на vc.ru.
MVP (minimum viable product, минимально жизнеспособный продукт) — это начальная версия продукта, в которой реализована главная ценность для потребителя, но нет полного функционала и, возможно, не до конца оформлена визуальная часть. Понять это просто: запомните принцип капкейка.
Перед продажей огромного торта нужно дать клиенту попробовать маленькое пирожное с той же начинкой. Понравится — будете масштабировать и доводить до идеала, нет — сэкономите деньги и время, а по замечаниям улучшите рецепт.
В разработке программного обеспечения всё то же самое. Перед созданием сложного софта есть смысл создать сначала прототип, протестировать его на реальных пользователях и только после этого «допиливать» и внедрять улучшайзинг.
Боитесь продавать кекс, потому что он совсем не торт и клиент будет недовольно морщить нос? Тогда эта статья для вас. Давайте только перенесёмся из кондитерской в опенспейс IT-компании и порассуждаем, может ли MVP стать адом для перфекциониста, какие страхи толкают заказчиков к бесконечной разработке и как с ними бороться, чтобы не было мучительно больно за бесцельно слитый бюджет.
Страх № 1. Продукт будет низкого качества и нанесёт урон репутации
Понятие MVP тесно связано с философией Agile. Заказчики иногда считают, что если продукт сделан быстро и без чёткого технического задания, значит, он сделан с кривым кодом и костылями. В таком случае неудивительно, что они хотят подстраховаться, долго готовят подробное ТЗ и избегают спешки.
«Мы не для того зарабатывали репутацию двадцать лет, чтобы испортить её за три месяца», — так говорят крупные бренды, которые хотят цифровизации, но настороженно относятся к MVP.
Страх оправдан или нет?
Моё мнение — нет! Не все конечные потребители вообще поймут, что MVP содержит только часть возможного функционала.
К сожалению, заказчики часто забывают, что качество сильно зависит от них самих. Огромный риск несут в себе слабые команды (на стороне клиента), которые не хотят работать по гибкой методологии, а работают по старинке: например, делают ТЗ целый год, в мельчайших подробностях.
Мой опыт говорит, что большинство потребителей оценивают качество продукта с MVP выше, чем без него.
Обратная связь от рынка поступает быстрее (выпуск MVP занимает в среднем три месяца).
Продукт постоянно развивается, улучшается, чтобы соответствовать требованиям покупателей, которые они доносят в обратной связи. Получается качественный и удобный софт, созданный под конкретные запросы клиентов.
Как бороться?
В первую очередь собрать внутри вашей компании команду людей, способных принимать решения. Они должны быть готовы к тому, что придётся жертвовать частью функционала и делать действительно капкейк, а не огромный торт. Никакого излишнего перфекционизма, сплошная прагматика. Команде необходимо понимать, каких функций для MVP достаточно, а от чего можно отказаться.
Если вы очень опасаетесь плохих отзывов об MVP, стоит выкатить релиз сначала на небольшую, самую лояльную аудиторию — friends & family, или несколько клиентов, с которыми будет легко договориться о пилотном запуске (в нашей практике большинство соглашается).
Пример 1: разработка страницы чекаута e-Commerce-продукта
С одним из IT-продуктов приключилась такая история. На странице чекаута было невозможно прикрутить полноценную форму оплаты, а запустить MVP нужно было срочно. Разработчики смогли предложить четыре варианта, как обойти проблему без ухудшения качества.
С онлайн-оплатой вообще интересная ситуация. Иногда кажется, что невозможность сделать оплату без перехода на сайт банка — это большая проблема, из-за которой может теряться часть продаж. Но мнение целевой аудитории может вас удивить: часть клиентов не доверяет такому формату и предпочитает, чтобы с сайта происходил переход на страницу банка (к ней больше доверия). Не всегда отсутствие дополнительного функционала означает низкое качество. Если на вашем сайте есть товар, который срочно нужен покупателю, в этом — главная ценность вашего MVP, и покупателю будут неважны прочие мелочи.
Пример 2: разработка B2B-портала
IT-компания разработала MVP для B2B-портала оптового поставщика и начала собирать обратную связь от реальных пользователей — ретейлеров, которые были достаточно лояльны и согласились принять участие в тестировании. Оказалось, что дилеры выбирают товар и собирают его в партии совсем не так, как представлял себе заказчик. Разработчики внесли изменения в MVP, и после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности). В этом кейсе и команда, и заказчик очень хорошо прочувствовали на себе, каких потерь помогает избежать MVP и насколько важно получать быструю обратную связь о продукте.
Пример 3: создание ТЗ длиной в год
Департамент нашего постоянного клиента попросил сделать объём по фикспрайсу. Мол, требования понятны, функционал простой, мы сами нарисуем макеты, вы только сделайте. Собрать ТЗ на «понятные» требования и подписать на них договор удалось только через год (!), ведь у заказчика есть работа, кроме согласования ТЗ, читать большой документ сложно и долго — пока обсуждаешь одну часть документа, забывается другая, через какое-то время нужно отредактировать уже ранее написанные части и так далее.
В итоге через два месяца разработки увольняется один из функциональных заказчиков, а «понятные и простые» требования после уточнения стали настолько сложными, что сам заказчик начал теряться в методике расчёта, которую сам же и предложил.
Страх № 2. Неопределённый бюджет на разработку
Бизнесу важно как можно точнее планировать бюджет, и мы как подрядчик, конечно, это понимаем.
Страх оправдан или нет?
С точки зрения планирования бюджета может показаться, что классический проектный подход выгоднее и проще, чем Agile. Подписали один документ с идеальным ТЗ на двенадцать миллионов — и ждём понятный результат. Но составить идеальное ТЗ невозможно: его просто не существует.
Разработка с ТЗ и без Agile обходится дороже по следующим причинам.
1. В ТЗ закладывают слишком много рисков и включают ненужные фичи.
При классическом проектном подходе заказчик стремится включить в ТЗ много ненужного про запас, в счёт рисков. Он думает: «Я не смогу изменить ТЗ потом, поэтому лучше заложить резерв заранее». Так проект становится действительно дорогим: в «запас» обычно идёт большое количество ненужных, непонятных фич, которые невозможно или сложно сделать. Например, заказчик требует функционал, который в реальной жизни работает не так, как в его мечтах. Выяснится это только при тестировании продукта одним из департаментов (который не посчитали нужным привлечь к созданию ТЗ). Запуск проекта придётся отодвинуть. Долгие циклы бизнес-аналитики, согласований и уточнения бюджета гарантированы. Другая крайность — в ТЗ попадают слишком размытые формулировки, зачастую специально только для того, чтобы какой-то отдел мог снять с себя ответственность.
В Agile над проектом работает фиксированная команда с фиксированной стоимостью. С этой командой можно (и нужно) договариваться; собственно, каждый спринт начинается с договорённости о том, какая ценность в конце спринта будет поставлена клиенту. Заказчик может любой бюджет тратить определённым образом, имея свободу корректировать и изменять ценности, отказываться от ненужных фич в пользу необходимых.
2. Клиент генерирует правки в самый последний момент.
Думаете, подробное ТЗ спасёт проект от корректировок и связанных с этим затрат? Практика показывает, что 99 % изменений клиенты требуют внести на самом последнем этапе, то есть на стадии приёмки. Представить готовый функционал заранее очень трудно, поэтому проект с абсолютно любым ТЗ будет требовать доработок. А значит, будут дополнительные циклы принятия бюджета. Ни о какой экономии не идёт речи, и согласовывать такой контракт тоже неудобно (шлифовать функционал можно бесконечно).
3. Принимать проект по ТЗ крайне затруднительно.
Представьте, вы тратите время на написание ТЗ и согласование его с департаментами (или это время тратят ваши сотрудники — неважно). Подрядчик оценивает этот объём и начинает работу. Далее он выдаёт объём работ большими частями, которые, соответственно, вам нужно тестировать большими кусками. Для проекта сложной разработки пройдёт минимум четыре месяца от старта: за это время кто-то может уволиться, в бизнесе может что-то измениться, само ваше видение идеала может стать совсем другим. В итоге, спустя несколько месяцев, вам приходит запрос на тестирование всего функционала, но не факт, что вы вообще помните, как он должен работать.
Принимать такие проекты — ад для заказчика. Подписывать акты страшно (вдруг чего-то не доглядели). Не подписывать тоже плохо — пока не подписан акт на большой объём работ, заказчик может отказываться реализовывать новый функционал.
Сколько уйдёт времени на тестирование даже двух месяцев работы команды разработчиков? Очень много. В Agile приняты короткие циклы (спринт длится 1–2 недели), за это время на приёмку работ у вас уходит мало времени, вы быстро даёте корректировки, и они очень быстро вводятся в эксплуатацию, где пользователи тоже начинают давать обратную связь.
4. Не виден результат.
Если оценивать результат через ROI (коэффициент возврата инвестиций), MVP выгоден более ранним получением прибыли.
Если же продукт изначально нерентабелен или вы допустили какую-то ошибку в своих начальных гипотезах, то с MVP вы быстро это поймёте и сможете перестроиться нужным образом. Выгода будет в уменьшении потерь.
Как бороться?
С гибкой методологией и MVP вы избавляетесь от большого количества лишних согласований. Команда работает на проекте столько, сколько понадобится; ежемесячные траты прозрачны и зависят от размера команды; вы определяете новые фичи в разработку и принимаете результат небольшими итерациями. Никто через четыре месяца не скажет вам, что разработчики сделали совсем не то, что ожидалось, и вам как менеджеру проекта не придётся нести ответственность за неточности в ТЗ. Разработчики будут заинтересованы не «сделать функционал по списку», а создать полезный продукт.
Пример: к каким убыткам приводит неоправданный перфекционизм
Одна известная нам команда делала интернет-магазин год! Год, и на этом ещё не всё! Проект не вышел в релиз, но уже пережил три редизайна просто потому, что клиент хочет довести проект до совершенства. А представления о совершенстве меняются регулярно (со сменой власти в компании, моды, погоды, политической обстановки...). И знаете, это не радует никого. Потому что бесконечная разработка не выгодна ни заказчику, ни исполнителю.
Потрачены миллионы рублей, но ни одной продажи ещё не было. Неизвестно, окупится ли этот проект. При разработке с MVP уже через три месяца была бы видна реакция рынка.
В итоге проект всё-таки запустился, но после запуска и начала содержательной работы всех департаментов над проблемами конкретных заказов (маркетинг, логистика, ДИТ) потребовалась смена концепции, а вместе с ней и дизайна, и многих технических моментов.
Страх № 3. Так никто не делает (в нашей нише, в нашем регионе и т. д.)
Страх оправдан или нет?
Методы гибкой разработки родились не вчера. Сам термин MVP появился примерно в 2001 году, но можно сказать, что предпосылки для этого были в истории научной организации труда, бережливого производства и улучшений маленькими шагами (Toyota, 1960-е годы). Сейчас работают с MVP многие, причём даже крупные бизнесы, которые на рынке очень давно. Яркие представители: «Додо Пицца», Dropbox, Uber, Airbnb, «Яндекс».
В разработке программного обеспечения вы не найдёте ни одну успешную и динамичную компанию, которая работает негибкими методологиями.
Как бороться?
Познакомьтесь с MVP поближе.
Рекомендую прочитать:
по теории:
- Дженнифер Грин, Эндрю Стеллман. «Постигая Agile. Ценности, принципы, методологии»;
- Эрик Рис. «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»;
по практике:
- глава из «Додо книги» на эту тему.
Пример: разнообразие проектов с MVP
Что радует: гибкие методы в разработке явно становятся популярнее.
MVP делают как для e-Commerce-продуктов, где основная сложность — в высокой нагрузке на сайт (с этим вообще легко — на MVP нужно просто регулировать трафик, ограничивая бюджет, и собирать web-аналитику), так и для продуктов с меньшим количеством пользователей, но уникальными техническими решениями.
Пример MVP для проекта с машинным зрением и нейросетью: сначала обучаем софт распознавать Х видов бумаг с качеством 60 %, потом каждый спринт добавляем новые образцы документов, подписей и печатей и повышаем процент качества. Для любых уникальных задач возможно создать MVP!
Вторая сторона этого страха — «так делают только стартапы»
Страх оправдан или нет?
Клиент может думать: «Стартапы работают в условиях неопределённости, поэтому им нужен MVP. А я в своём бизнесе много лет и точно знаю, чего хочу от разработчиков. Мне нужен очень простой софт. Здесь должна быть такая кнопка, а это поле должно быть таким. Зачем мне MVP?» Здесь простота — это иллюзия.
Не только стартап, но и крупный бизнес — с 10-, 20-летним опытом работы и более — при разработке программного обеспечения всегда встречается с неопределённостью.
Во-первых, ситуация на рынке и тренды в маркетинге меняются очень быстро, за ними сложно уследить. Ещё быстрее меняется поведение конечных пользователей, ведь каждую секунду они получают новый опыт от других компаний. Это можно назвать внешней неопределённостью.
Во-вторых, есть внутренняя неопределённость (со стороны заказчика): чем больше людей принимают решение, тем сложнее им договориться, как именно должен работать продукт.
Простой пример: заказчик думает, что форма утверждения сырья на склад очень простая, ведь его сотрудники делают это вручную каждый день. Но при автоматизации выясняется то, на что взгляд был «замылен», — оказывается, по номеру исходной накладной исполнитель должен понять номер партии, и ввод количества сырья будет запрашиваться на основе тех знаний, которые в разработке софта не учитывались и никак не оцифровывались. Заказчик был уверен, что задача простая и определённая!
Как бороться?
Оценить внешние и внутренние факторы неопределённости вокруг вашего бизнеса. Вспомнить, сколько времени занимает согласование важных документов в вашей компании. И сколько ошибок в процессе приходится исправлять.
Оценить потери времени в денежном эквиваленте за год.
Пример: иллюзия ясности
Небольшая компания, ориентированная на B2B-клиентов, заказала софт для внутреннего использования по негибким методологиям. Казалось бы, простой продукт для малого количества пользователей. Компания на рынке давно, опыт в ведении дел у всех сотрудников — более 10 лет.
Согласование договора заняло год.
Когда подрядчики принимали задачу и уточняли требования к связанности полей, они так долго обсуждали каждый шаг, что было ясно: в отделе каждый из четырёх человек понимает проект по-своему. Более того, они не знали собственные бизнес-процессы. А когда автоматизируешь бизнес-процессы, ты не можешь автоматизировать хаос. Нельзя оцифровать такой принцип назначения ответственного: «обычно это делал Петя, но сейчас пусть сделает Вася, кажется, он сейчас свободен». Необходим чёткий алгоритм, и возникает большое количество вопросов к системе.
Организация была далека от стадии стартапа, но это не помогло ей избежать внутренних факторов неопределённости.
Страх № 4. Это сложно, придётся напрягаться
Страх оправдан или нет?
Перед каждым спринтом нужно принимать управленческое решение о том, что важно для реализации на следующий спринт (обычно в разработке спринт занимает 1–2 недели, а в машиностроении — 2–3 месяца, главное — ритмичность!). Это тяжело в том случае, если в вашей компании нет сильного менеджера, лидера, который может чётко ставить цели на следующие две недели. Или когда в компании слишком много лиц, принимающих решение, и они не могут договориться.
Как бороться?
Прокачать своих управленцев. Изучить методы INVEST (или SMART) и Impact Mapping: это метод описания задач, который позволяет максимально глубоко продумать задачу со стороны пользовательской ценности, и методика, согласно которой конкретная задача ложится на улучшение конкретных показателей.
В серьёзных IT-компаниях, кроме разработчиков, есть ещё проектный менеджер, который владеет методами INVEST и Impact Mapping и помогает заказчику прийти к нужным формулировкам (но, конечно, не без участия менеджмента со стороны клиента).
Пример: как MVP решает проблему мучительных согласований
Без долгих согласований можно запустить пробную версию и дополнять, улучшать её в каждом спринте. Принимать решения об улучшениях маленькими шагами нелегко, но обычно это проще, чем согласовать сразу крупный проект! Соседние департаменты теперь не винят друг друга в том, что кто-то что-то не учёл, а содержательно обсуждают план действий на следующие две недели.
Вывод
Итак, резюмирую: MVP — это средство контакта с реальностью, которое помогает быстрее получить обратную связь и подстроиться под требования пользователей системы.
Гибкие методологии выгодны всем (и заказчику, и подрядчику, и конечному пользователю), они повышают осознанность управления бизнесом.
Надеемся, эта статья хоть немного развеяла страхи, окружающие MVP.
